2. Reviewing and Configuring Message Routing Between Active Directory Sites
Hub Transport servers route messages to other Hub Transport servers based on the Active Directory site and site link topology. Therefore, for Exchange 2010 to work correctly, it is crucial that the Active
Directory topology does not cause any negative effects on message
routing or Exchange servers. This section focus on how to make sure
that your Active Directory site topology is suitable for Exchange 2010
and what you can do to modify the topology with Exchange-related
settings.
2.1. Review Active Directory Site and Site Links Topology
Before you consider
configuring Active Directory sites and Active Directory site links to
optimize message routing, you need to clearly understand the current
Active Directory topology of your organization. You can do this using
the Active Directory Sites and Services snap-in. However, in a large
environment with many Active Directory sites and site links, you may
lose the overview. For that reason you can also use a tool called Microsoft
Active Directory Topology Diagrammer that allows you to visualize the
Active Directory topology in a Microsoft Office Visio file. The tool
was tested with Visio 2003 or Visio 2007. Having a graphical
representation that you can put on the wall helps you to identify areas
that might need to be optimized for message routing. Figure 2 shows an example of a diagram created from the Litware Scenario. The tool can be downloaded at http://www.microsoft.com/downloads/details.aspx?familyid=cb42fc06-50c7-47ed-a65c-862661742764&displaylang=en.
2.2. Configuring Active Directory Sites
An Active Directory
site is a logical definition of a physical connected network, normally
based in the same local area network (LAN) and thus sharing a very fast
network connection within the Active Directory site. You define a site
based on an IP subnet in the Active Directory Sites and Services
snap-in. The primary purpose for creating an Active Directory site is
to define which subnets in the network are connected in a way that
optimizes control of Active Directory replication traffic.
The Active Directory site is a routing boundary for Hub Transport
servers to make routing decisions based the Active Directory site
topology as described in the previous chapter. To meet this requirement
you must make sure that every Exchange server role belongs to an Active
Directory site. You should also verify that each Active Directory site
is based on one or more subnets based on LAN-quality networks.
Otherwise, consider splitting these Active Directory sites into multiple sites.
You can get a list of all Exchange servers and their respective Active Directory site using the following cmdlet: Get-ExchangeServer | ft Name, Site.
Note: Many
companies split the administration between the Active Directory forest
and Exchange into different teams. If this describes your situation,
you need to remember that you can only configure Active Directory sites
and Active Directory site links if the Active Directory team has
provided you with sufficient permission and you have secured the buy-in
from that team to make the changes to the production Active Directory
infrastructure.
2.3. Configuring Site Links and Site Link Costs
Site links are logical paths between
Active Directory sites and always include a site link cost to be able
to configure specific routes for Active Directory replication traffic.
The same information is used by Exchange 2010 to calculate the
least-cost routing path.
Note: Site
links are only used for routing when direct Hub Transport server to Hub
Transport server connections are not possible. The vast bulk of
deliveries occur via direct connections.
A site link does not force
the actual path that is taken by network packets on the physical
network but define the way Active Directory replication is done within
the forest. However, every so often the cost assignment to the site
link typically relates to the underlying network speed and available
bandwidth.
It is important for the
Exchange designer to understand the site topology as well as the site
links and site link costs to make sure that Exchange routing is done as
defined. To verify how Exchange uses the current topology, you can use
the Routing Table Log Viewer after the first Exchange 2010 server is
installed in the forest. If an Exchange server is not yet installed,
use the Microsoft Active Directory Topology Diagrammer to get an Active Directory topology overview.
|
Brian Day
Senior Systems Administrator, Messaging & Directory Services, Commonwealth of Massachusetts
Active Directory site link
costs: What can they cost you? Misconfigured site link costs can cost
you hours of frustration if not planned correctly from the start.
In 2005 I
joined an employer whose Active Directory architecture was very complex
across hundreds of physical sites, and a little bit out of control. It
grew faster than anyone expected and some things got overlooked,
including site link configuration. Part of my role was to help clean up
the environment and optimize it where possible. At the time, WAN
connections for these hundreds of sites were primarily all frame relay,
ranging in speeds from 384 Kbps to multiple T-1 circuits bonded
together. Site link costs were of the Wild West variety, with no
uniformity. Values existed from more than 1,000 all the way down to 10
and anything in between, even though we only had 5 or 6 different speed
links. In many cases circuits of the same speed didn't have the same
costs. Taking a step back and looking at the situation I could see what
had happened—there was no proper planning for the future and multiple
schemes were actually in use regarding site link cost, depending on who
had originally entered the site links.
I knew I had to find a way to
future-proof ourselves and come up with a way to deal with new WAN
connections in the future without having to go back and reconfigure old
ones every couple of years. While researching methods other people use
to determine costs I found a great article on Microsoft TechNet called
"Determining the Cost" available at http://technet.microsoft.com/en-us/library/cc782827(WS.10).aspx. Buried on this page was a formula Microsoft suggested for site link costs: [1024/Log10(Kbps of WAN Link)]=Cost.
At first glance I looked at this and thought, What mathematics nerd had
too much time on his hands? That is, until I gave it an honest try.
Suddenly I had a desire to call my old math teacher and let him know that logarithms did actually end up being useful in the real world! As you can see in Table 3,
the formula provided us with costs that can grow (and shrink) as WAN
speeds matured, becoming faster and faster. It also left enough space
between costs so that I could configure primary/secondary site links by
creating a second site link with a value of Cost+1.
I've often seen people establish costs with no space between them,
leaving no room for this type of configuration. Perhaps if you have
other finicky site links that have the speed but are not always the
most reliable (like a satellite connection) compared to other site
links of similar throughput, you could also adjust them by bumping the
cost a couple points. I have a sneaking suspicion that I will be gone
from this planet by the time WAN connections exist that are fast enough
to cause this formula to reach the lowest value of 1.
|
Table 3. Site Link Costs Defined by Bandwidth
| DESCRIPTION | KBPS | SITE LINK COST |
|---|
| Dialup | 56 | 586 |
| ISDN BRI | 128 | 486 |
| 256 | 425 |
| 384 | 396 |
| 512 | 378 |
| 1024 | 340 |
| T1 | 1582 | 320 |
| 2048 | 309 |
| 10 Mbps | 10240 | 255 |
| 100 Mbps | 102400 | 204 |
| GigE6 | 307200 | 187 |
| 1000 Mbps | 1024000 | 170 |
2.4. Configuring Exchange Specific Settings for Site Links
The Active Directory site topology might not be optimal for Exchange message routing
in specific cases. Therefore, you can assign an Exchange-specific cost
to the site link that Exchange can use for routing purposes. The
Exchange-specific cost for the IP site link will not modify or affect
the current Active Directory site cost that is used for replication. Of
course, if you set an Exchange
cost, you will override the Active Directory cost for message-routing
purposes, but this won't interfere with Active Directory replication.
After reviewing your Active Directory site topology and installing your Exchange servers in the right Active
Directory sites, you should carefully consider whether you need to
implement Exchange-related IP site link costs, which are quite hard to
manage. They only make sense in large deployments where you have many
Active Directory sites with Active Directory site
links that are not in the control of Exchange and are known to be
changed without your notification. Don't try to configure a message
routing path—remember that most of the time the Hub Transport servers communicate directly to each other anyway.
Consider the
Litware Scenario where the IP Site Link SiteLinkWorld is configured
with a cost of 100. The following Exchange Management Shell (EMS)
cmdlet assigns an Exchange-specific cost of 20 to it:
Set-ADSiteLink -Identity "SiteLinkWorld" -ExchangeCost 20
Note: You can also use the Set-AdSiteLink –Identity <ADSiteLink> – MaxMessageSize <value> cmdlet to assign a maximum message size limit for messages sent between Active Directory sites. This is especially useful if you have branch offices that have low-bandwidth network links
so that you make sure only small messages can be sent over the network.
All the larger messages will generate a non-delivery report (NDR).
As shown in Figure 3 the Active Directory site link still has the Active Directory cost
of 100, but additionally has an Exchange cost of 20 assigned, and a
message size limit is not configured. From now on, least-cost routing calculation will consider only the Exchange cost and ignore the Active Directory cost.
|
Ulf Hansen
Principal Systems Administrator, Central Administration Exchange, Siemens AG (Germany)
My company has a very large forest with more than 1,000 different Active
Directory sites and many hundreds of IP site links. Domain
administration is done independently and administrators have a huge
influence on configuring their Active Directory sites because Active
Directory sites are also used for services other than Exchange. Thus we
started first to think about building Active Directory sites just for
Exchange to be in charge of the routing costs, but finally decided
against it.
Because we were not in
charge of defining the Active Directory costs and we did not want to
interfere or change our complex Active Directory routing in any way, we
agreed to configure all Active Directory sites automatically with the
maximum cost of 999. As a result, Exchange considers all Active
Directory sites equal and uses the route with the fewest hops as the
least-cost route.
Remember, Exchange costs
will be used over Active Directory costs, and if multiple paths are
available with the same costs, the path with the fewest hops is
selected if a direct connection to a Hub Transport server in the target Active Directory site cannot be made.
We discovered that
messages didn't take the route that we anticipated; our solution was to
reduce the Exchange cost to force messages and correct the routing.
However, we still see some limitations when Active Directory costs are
used that cause problems in our Exchange environment. For example,
Public Folder stores that have an AD cost of more than 500 from the
Exchange server are not considered for Outlook 2003 Free/Busy Public
Folder lookups.
|
2.5. Configuring Hub Sites
One way to interfere with the least-cost routing path is by defining hub
sites through which all message flow must be relayed. You can think of
this situation as a form of hub-and-spoke design with a messaging
backbone.
You might have hub sites if a firewall prevents direct communication between certain Active
Directory sites or if a company policy exists whereby all message
traffic must be routed through a special Active Directory site.
Note: A
hub site is considered only when it is located on the least-cost
routing path calculated by the Hub Transport server. The source Hub
Transport server always calculates the lowest-cost route first, and
then determines whether any of the sites on the route are hub sites. If
the lowest-cost route does not include a hub site, the Hub Transport
server will directly connect to a Hub Transport server in the target
site.
Before you implement hub sites, it is important that you review your Active
Directory topology to make sure that the least-cost routing path always
includes the Active Directory sites you want to define as hub sites.
You can view all hub sites available using the Get-AdSite cmdlet and configure them using the Exchange Management Shell and the Set-AdSite cmdlet. You have to do this site by site, so keep track of the changes you make!
The following cmdlet shows an example where Site-Berlin is configured as a hub site:
Set-AdSite -Identity „Site-Berlin" -HubSiteEnabled $true
2.6. Configuring Expansion Servers for Distribution Groups
You also can modify the default routing topology by assigning expansion servers for distribution groups.
By default, when a message is sent to a distribution group, the first
Hub Transport server that receives the message expands the distribution
list and calculates how to route the messages to each recipient in the
list.
If you configure an expansion
server for the distribution list, all messages sent to the distribution
list are sent to the specified Hub Transport server, which then expands the list and distributes the messages. For example, you can use expansion servers for location-based distribution
groups to ensure that the local Hub Transport server resolves them.
This configuration only sends one message addressed to a location-based
distribution to the location and is then expanded at the target
location by the defined expansion server.
Note: Because
you only can define a single Hub Transport server, distribution list
expansion will fail if this expansion server is not available. Thus you
might negatively impact your message flow. There is no way to configure
more than one expansion server, so you have to decide either to use one
expansion server or let the distribution list expand at all servers.
Even though distribution
group expansion was available in previous Exchange versions, it is
improved in Exchange 2010 in two ways: You can now configure a memory caching limit to prevent the cache from consuming too much memory, and the processing of large distribution groups with delivery restrictions is done more efficiently.
You configure the distribution group cache by adding the parameters as found in Table 4 to the EdgeTransport.exe.config file located at <Exchange_Server_Install>\Bin.
Table 4. Parameters to Configure Distribution Group Cache
| PARAMETER | DESCRIPTION |
|---|
| MaxResolveRecipientCacheSize | This
cache is only used to avoid duplicate delivery to one-offs and
distribution lists (DLs). So if you notice that delivery to some DLs
(with more entries than this cache size) still result in duplicate
deliveries, you can make the size larger. The Information Store would
still do duplicate detection, but this feature is to prevent from
trying to deliver in the first place. |
| MaxResolverMemberOfGroupCacheSize | This
cache includes group members for the sender. So if a person sends to a
DL, this cache tracks membership of that person so that if restrictions
apply to any sub DL, it doesn't have to be looked up again. You would
want to make this larger if you notice a lot of Active Directory queries for messages to large DLs with complex delivery restrictions. |
2.7. Verifying Configuration Using the Routing Log Viewer
The Routing Log Viewer is one of the most important tools to understand how Exchange is interpreting your configuration changes in means of Active Directory sites, Active Directory site links, and so on. You use the Routing Log Viewer to open a local Routing Table log file located on your Hub or Edge Transport servers.
Note: The
Routing Log Viewer only shows you the routing table of a single Hub
Transport server. This means you always need to connect to the Hub
Transport server that causes the message routing problem to investigate
its local routing table. If you are connected to a different transport
server, you might not be able to detect the issue!
After opening a routing
table log file (normally you open the latest one available), the
routing table is organized into four tabs: Active Directory Sites (and
Routing Groups if you have Exchange 2003 servers in your organization),
Servers, Send Connectors, and Address Spaces.
If you want to read more about the Routing Log Viewer and how to use it, the TechNet article "Viewing the Routing Table Log" is available at http://technet.microsoft.com/en-us/library/bb691033(EXCHG.80).aspx.
2.7.1. Active Directory Sites Tab
On this tab you can make
sure that your Exchange servers belong to the correct Active Directory
site, and also determine whether any Hub sites are identified
incorrectly. You can also see the least cost to each of the other sites
by identifying the Total Active Directory cost item, as shown in Figure 4. You do not see the difference between
Active Directory costs and Exchange costs assigned to an Active
Directory site link, but the routing table just provides you with the
cost information used by the Hub Transport server.
2.7.2. Servers Tab
The Servers tab provides
an overview of all Exchange servers in your Exchange organization. You
get an overview of the roles installed, the routing cost to reach the server, any MDB databases (mailbox databases) available on this server, and its Legacy DN.
2.7.3. Send Connectors Tab
This tab provides you with an
overview of send connectors that are available for this specific Active
Directory site, as shown in Figure 5.
It includes the address space, information about the proximity of the
connector, whether the message is delivered using a smart host or DNS,
whether it is a scoped connector, and the message size restriction set
on it.
Note: Scoped
connectors are only available in the local Active Directory site—thus
the address space of a scoped connector does not show up in another
Active Directory site's Send Connector tab.
2.7.4. Address Space Tab
The Address Space tab provides a hierarchical list including all address spaces available for this Hub Transport server. You can expand the list until you find the Send connector that serves the address space.
This tab is especially important
in organizations that have many address spaces configured, which might
also have a lot of connectors. In this situation it is maybe easier to
search for a Send connector by looking through the available address
spaces on this tab than to examine the connectors listed on the Send
Connector tab.
